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Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
community. This memo does not specify an Internet standard of any 
kind. Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


1. INTRODUCTION SECTION 


This document is a description of the Enhanced Trivial File Transfer 
Protocol (ETFTP). This protocol is an experimental implementation of 
the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file 
transfer application program. It uses the User Datagram Protocol 
(UDP), RFC 768 [2], as its transport layer. The two protocols are 
layered to create the ETFTP client server application. The ETFTP 
program is named after Trivial File Transfer Protocol (TFTP), RFC 
1350 [3], because the source code from TFTP is used as the building 
blocks for the ETFTP program. This implementation also builds on but 
differs from the work done by the National Imagery Transmission 
Format Standard [4]. 


This document is published for discussion and comment on improving 
the throughput performance of data transfer utilities over Internet 
Protocol (IP) compliant, half duplex, radio networks. 


There are many file transfer programs available for computer 
networks. Many of these programs are designed for operations through 
high-speed, low bit error rate (BER) cabled networks. In tactical 
radio networks, traditional file transfer protocols, such as File 
Transfer Protocol (FTP) and TFTP, do not always perform well. This is 
primarily because tactical half duplex radio networks typically 
provide slow-speed, long delay, and high BER communication links. 
ETFTP is designed to allow a user to control transmission parameters 
to optimize file transfer rates through half-duplex radio links. 


Polites, Wollman & Woo Experimental [Page 1] 


RFC 1986 ETFTP August 1996 


The tactical radio network used to test this application was 
developed by the Survivable Adaptive Systems (SAS) Advanced 
Technology Demonstration (ATD). Part of the SAS ATD program was to 
address the problems associated with extending IP networks across 
tactical radios. Several tactical radios, such as, SINgle Channel 
Ground and Airborne Radio Systems (SINCGARS), Enhanced Position 
Location Reporting Systems (EPLRS), Motorola LST-5C, and High 
Frequency (HF) radios have been interfaced to the system. This 
document will discuss results obtained from using ETFTP across a 
point-to-point LST-5C tactical SATellite COMmunications (SATCOM) 
link. The network includes a 25 Mhz 486 Personal Computer (PC) called 
the Army Lightweight Computer Unit (LCU), Cisco 2500 routers, 
Gracilis PackeTen Network switches, Motorola Sunburst Cryptographic 
processors, a prototype forward error correction (FEC) device, and 
Motorola LST-5C tactical Ultra High Frequency (UHF) satellite 
communications (SATC! OM) radio. Table 1, "Network Trans fer Rates," 
describes the equipment network connections and the bandwidth of the 
physical media interconnecting the devices. 


Table 1: Network Transfer Rates 


4$-------------------- S 4$------------------- e aS + 
| Equipment | Rate (bits per second) 
4$------------------- A a SS ee a ee + 
| Host Computer (486 PC) | 10,000,000 Ethernet | 
AREETA C AT atacier ecto ae cacheea Pree s eS See Se See ese Sees + 
| Cisco Router | 10,000,000 Ethernet to 
19,200 Serial Line Internet 
Protocol (SLIP) 
4$—------------ 5-5-5555 4-------------------- 5-5-5 + 
| Gracilis PackeTen | 19,200 SLIP to 
| | 16,000 Amateur Radio (AX.25) | 
a A A 5-5 Toena aa + 
| FEC | half rate or quarter rate | 
E A A E S fa Se + 
| Sunburst Crypto | 16,000 
6 a E ee pS Ss Se Se See oes + 
| LST-5C Radio | 16,000 | 
eo SSS Se oe Se eS eee {pS eS ee ae + 


During 1993, the MITRE team collected data for network configurations 
that were stationary and on-the-move. This network configuration did 
not include any Forward Error Correction (FEC) at the link layer. 
Several commercially available implementations of FTP were used to 
transfer files through a 16 kbps satellite link. FTP relies upon the 
Transmission Control Protocol (TCP) for reliable communications. For 
a variety of file sizes, throughput measurements ranged between 80 
and 400 bps. At times, TCP connections could be opened, however, data 
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transfers would be unsuccessful. This was most likely due to the 
smaller TCP connection synchronization packets, as compared to the 
TCP data packets. Because of the high bit error rate of the link, 
the smaller packets were much more likely to be received without 
error. In most cases, satellite channel utilization was less than 20 
percent. Very often a file transfer would fail because FTP 
implementations would curtail the transfer due t! o the poor 
conditions of the commu nication link. 


The current focus is to increase the throughput and channel 
utilization over a point to point, half duplex link. Follow on 
experiments will evaluate ETFTP’s ability to work with multiple hosts 
in a multicast scenario. Evaluation of the data collected helped to 
determine that several factors limited data throughput. A brief 
description of those limiting factors, as well as, solutions that can 
reduce these networking limitations is provided below. 


Link Quality 


The channel quality of a typical narrow-band UHF satellite link does 
not sufficiently support data communications without the addition of 
a forward error correction (FEC) capability. From the data 
collected, it was determined that the UHF satellite link supports, on 
average, a 10e-3 bit error rate. 


Solution: A narrow-band UHF satellite radio FEC prototype was 
developed that improves data reliability, without excessively 
increasing synchronization requirements. The prototype FEC increased 
synchronization requirements by less than 50 milliseconds (ms). The 
FEC implementation will improve an average 10e-3 BER channel to an 
average 10e-5 BER channel. 


Delays 


Including satellite propagation delays, the tactical satellite radios 
require approximately 1.25 seconds for radio synchronization prior to 
transmitting any data across the communication channel. Therefore, 
limiting the number of channel accesses required will permit data 
throughput to increase. This can be achieved by minimizing the number 
of acknowledgments required during the file transfer. FTP generates 
many acknowledgments which decreases throughput by increasing the 
number of satellite channel accesses required. 


To clarify, when a FTP connection request is generated, it is sent 
via Ethernet to the router and then forwarded to the radio network 
controller (RNC). The elapsed time is less than 30 ms. The RNC keys 
the crypto unit and 950 ms later modem/crypto synchronization occurs. 
After synchronization is achieved, the FTP connection request is 
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transmitted. The transmitting terminal then drops the channel and the 
modem/crypto synchronization is lost. Assuming that the request was 
received successfully, the receiving host processes the request and 
sends an acknowledgment. Again the modem/crypto have to synchronize 
prior to transmitting the acknowledgment. Propagation delays over a 
UHF satellite also adds roughly 500 ms to the total round trip delay. 


Solution: When compared to FTP, NETBLT significantly reduces the 
number of acknowledgments required to complete a file transfer. 
Therefore, leveraging the features available within an implementation 
of NETBLT will significantly improve throughput across the narrow- 
band UHF satellite communication link. 


To reduce the number of channel accesses required, a number of AX.25 
parameters were modified. These included the value of p for use 
within the p-persistence link layer protocol, the slot time, the 


transmit tail time, and the transmit delay time. The p-persistence 
is a random number threshold between 0 and 255. The slot time is the 
time to wait prior to attempting to access the channel. The transmit 


tail increases the amount of time the radio carrier is held on, prior 
to dropping the channel. Transmit delay is normally equal to the 
value of the radio synchronization time. By adjusting these 
parameters to adapt to the tactical satellite environment, improved 
communication performance can be achieved. 


First, in ETFTP, several packets within a buffer are transmitted 
within one burst. If the buffer is partitioned into ten packets, each 
of 1024 bytes, then 10,240 bytes of data is transmitted with each 
channel access. It is possible to configure ETFTP’s burstsize to 
equal the number of packets per buffer. Second, the transmit tail 
time was increased to hold the key down on the transmitter long 
enough to insure all of the packets within the buffer are sent ina 
single channel access. These two features, together, allow the system 
to transmit an entire file (example, 100,000 bytes) with only a 
single channel access by adjusting buffer size. Thirdly, the ETFTP 
protocol only acknowledges each buffer, not each packet. Thus, a 
single acknowledgment is sent from the receiving terminal containing 
a request for the missing packets within each buffer, reducing the 
number of acknowledgment packets sent. Which in turn, reduced the 
number of times the channel has to be turned around. 


To reduce channel access time, p-persistence was set to the maximum 
value and slot time to a minimum value. These settings support 
operations for a point-to-point communication link between two users. 
This value of p would not be used if more users were sharing the 
satellite channel. 
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Backoffs 


TCP’s slow start and backoff algorithms implemented in most TCP 
packages assume that packet loss is due to network congestion. When 
operating across a tactical half duplex communication channel 
dedicated to two users, packet loss is primarily due to poor channel 
quality, not network congestion. A linear backoff at the transport 
layer is recommended. In a tactical radio network there are numerous 
cases where a single host is connected to multiple radios. Ina 
tactical radio network, layer two will handle channel access. 

Channel access will be adjusted through parameters like p-persistence 
and slot time. The aggregate effect of the exponential backoff from 
the transport layer added to the random backoff of the data link 
layer, will in most cases, cause the radio network to miss many 
network access opportunities. A linear backoff will reduce the number 
missed data link network access opportunities 


Solution: Tunable parameters and timers have been modified to 
resemble those suggested by NETBLT. 


Packet Size 


In a tactical environment, channel conditions change rapidly. 
Continuously transmitting large packets under 10e-3 BER conditions 
reduces effective throughput. 


Solution: Packet sizes are dynamically adjusted based upon the 
success of the buffer transfers. If 99 percent of all packets within 
a buffer are received successfully, packet size can be increased to a 
negotiated value. If 50 percent or more of all packets within a 
buffer are not successfully delivered, the packet size can be 
decreased to a negotiated value. 


2. PROTOCOL DESCRIPTION 


Throughout this document the term packet is used to describe a 
datagram that includes all network overhead. A block is used to 
describe information, without any network encapsulation. 


The original source files for TFTP, as downloaded from ftp.uu-.net, 
were modified to implement the ETFTP/NETBLT protocol. These same 
files are listed in "UNIX Network Programming" [5]. 


ETFTP was implemented for operations under the Santa Cruz Operations 
(SCO) UNIX. In the service file, "/etc/services", an addition was 
made to support "etftp" at a temporary well known port of "1818" 
using "UDP" protocol. The file, "/etc/inetd.conf", was modified so 
the "inetd" program could autostart the "etftpd" server when a 
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connection request came in on the well known port. 


As stated earlier, the transport layer for ETFTP is UDP, which will 
not be discussed further here. This client server application layer 
protocol is NETBLT, with four notable differences. 


The first change is that this NETBLT protocol is implemented on top 
of the UDP layer. This allowed the NETBLT concepts to be tested 
without modifying the operating system’s transport or network layers. 
Table 2, "Four Layer Protocol Model," shows the protocol stack for 
FTP, TFTP and ETFTP. 


Table 2: Four Layer Protocol Model 


4-------------------------------------------------- === === ------ + 
| PROTOCOL STACK | 
4+--------------- 4--------------- 4+--------------- 4+--------------- + 
| APPLICATION |FTP | TETP |ETFTP/NETBLT | 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
| TRANSPORT | TCP | UDP | UDP | 
4+--------------- 4+--------------- 4--------------- 4+--------------- + 
| NETWORK | IP | 
+--------------- 4+--------------- 4+--------------- 4+--------------- + 
| LINK |Ethernet, SLIP, AX.25 | 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 


The second change is a carryover from TFTP, which allows files to be 
transferred in netascii or binary modes. A new T bit flag is assigned 
to the reserved field of the OPEN message type. 


The third change is to re-negotiate the DATA packet size. This change 
affects the OPEN, NULL-ACK, and CONTROL_OK message types. A new R 
bit is assigned to the reserved field of the OPEN message type. 


The fourth change is the addition of two new fields to the OPEN 
message type. The one field is a two byte integer for radio delay in 
seconds, and the next field is two bytes of padding. 


The ETFTP data encapsulation is shown in Table 3, "ETFTP Data 
Encapsulation,". The Ethernet, SLIP, and AX.25 headers are mutually 
exclusive. They are stripped off and added by the appropriate 
hardware layer. 
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Table 3: ETFTP Data Encapsulation 


+------------ +------------ +-----------—- +-----------—- +----------- + 
|Ethernet (14) | | |ETFTP/ | | 
| SLIP (2) | IP (20) | UDP (8) |NETBLT(24)  |DATA(1448) 
|Ax.25 (20) | | | | | 
+-----------—- +------------ +------------ +-----------—- +----------- + 

Zot MESSAGE TYPES AND FORMATS 


Here are the ETFTP/NETBLT message types and formats. 


MESSAGES VALUES 

OPEN 0 Client request to open a new connection 
RESPONSE 1 Server positive acknowledgment for OPEN 
KEEPALIVE 2 Reset the timer 

QUIT 3 Sender normal Close request 


QUITACK 4 Receiver acknowledgment of QUIT 
ABORT 5 Abnormal close 


DATA 6 Sender packet containing data 
LDATA 7 Sender last data block of a buffer 
NULL-ACK 8 Sender confirmation of CONTROL_OK changes 
CONTROL 9 Receiver request to 
GO 0O Start transmit of next buffer 
OK 1 Acknowledge complete buffer 


RESEND 2 Retransmit request 
REFUSED 10 Server negative acknowledgment of OPEN 
DONE 11 Receiver acknowledgment of QUIT. 


Packets are "longword-aligned", at four byte word boundaries. 
Variable length strings are NULL terminated, and padded to the four 
byte boundary. Fields are listed in network byte order. All the 
message types share a common 12 byte header. The common fields are: 


Checksum IP compliant checksum 
Version Current version ID 

Type NETBLT message type 

Length Total byte length of packet 
Local Port My port ID 

Foreign Port Remote port ID 


Padding Pad as necessary to 4 byte boundary 
The OPEN and RESPONSE messages are similar and shown in Table 4, 


"OPEN and RESPONSE Message Types,". The client string field is used 
to carry the filename to be transferred. 
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Table 4: OPEN and RESPONSE Message Types 


an 2 3 

IZ 3.4 5 6 T BO Od. Qe 3245.6) 7 BOO LB 3 ALS OY 89 OF 22 
+--------------- +--------------- +--------------- +--------------- + 
| Checksum | Version | Type 
+--------------- +--------------- +--------------- 4+--------------- + 
|Length |Local Port | 
4+--------------- 4+--------------- +--------------- +--------------- + 
|Foreign Port | Longword Alignment Padding | 
$aSHSSaaseeaases $=SSS58SS5S$S5=5 $=sSSse—5S$SsH5=5 $=SS555SSS-saS=5 + 
|Connection ID | 
SS orien ana gn esteniar an a eaten Jonn ese SSeS SS Sc Sa a a ac ca IR Jonn RSS SS SSSS SSS + 
|Buffer size | 
A E phre enge S I E phren easg + 
|Transfer size | 
+--------------- +--------------- +--------------- +--------------- + 
|DATA Packet size |Burstsize 
+--------------- +--------------- +--------------- +--------------- + 
|Burstrate |Death Timer Value | 
+--------------- +--------------- +--------------- 4+--------------- + 
| Reserved (MBZ) |R|T|C|M|Maximum # Outstanding Buffers | 
+e oSS-5S5SsS5-55 FesSSssSsssSses- +p SSS A Farer rA + 
|*Radio Delay | *Padding 

+o SSS SSS SSeesSS5 Ga at Fess aA yn SSH a ao a + 
|Client SEPING i 2-8 | Longword Alignment Padding 
$assSessseosss= patetes taret FRsSS-ossaSe-== + 
Connection ID The unique connection number 
Buffer size Bytes per buffer 

Transfer size The length of the file in bytes 

DATA Packet size Bytes per ETFTP block 

Burstsize Concatenated packets per burst 

Burstrate Milliseconds per burst 

Death Timer Seconds before closing idle links 

Reserved M bit is mode: O=read/put, l=write/get 


C bit is checksum: O=header, 1=all 

*T bit is transfer: O=netascii, l=binary 

*R bit is re-negotiate: O=off, l=on 
Max # Out Buffs Maximum allowed un-acknowledged buffers 
Radio Delay *Seconds of delay from send to receive 
Padding *Unused 
Client String Filename. 


The KEEPALIVE, QUITACK, and DONE messages are identical to the common 


header, except for the message type values. See Table 5, “KEEPALIVE, 
QUITACK, and DONE Message Types,". 
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Table 5: KEEPALIVE, QUITACK, and DONE Message Types 


i; 2 3 

IZ 34 6 7 8-9 Od. 2 3A D6 T 8-9 L 2 AGT g OF 12 
4+--------------- 4+--------------- 4--------------- 4--------------- + 
| Checksum | Version | Type 

4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
| Length |Local Port | 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
|Foreign Port | Longword Alignment Padding | 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 


The QUIT, ABORT, and REFUSED messages allow a string field to carry 
the reason for the message. See Table 6, "QUIT, ABORT, and REFUSED 
Message Types,". 


Table 6: QUIT, ABORT, and REFUSED Message Types 


1 2 3 

L23 45 678 9OQ123 45678 9012345678 9 0 1 2 
4+--------------- 4--------------- 4+--------------- 4--------------- + 
| Checksum | Version | Type 

4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
|Length |Local Port | 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
|Foreign Port | Longword Alignment Padding | 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
|Reason for QUIT/ABORT/REFUSED . . . | 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
E Se | Longword Alignment Padding | 
4--------------- 4+--------------- 4+--------------- 4+--------------- + 


The DATA and LDATA messages make up the bulk of the messages 
transferred. The last packet of each buffer is flagged as an LDATA 
message. Each and every packet of the last buffer has the reserved L 
bit set. The highest consecutive sequence number is used for the 
acknowledgment of CONTROL messages. It should contain the ID number 
of the current CONTROL message being processed. Table 7, "DATA and 
LDATA Message Types,", shows the DATA and LDATA formats. 
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Table 7: DATA and LDATA Message Types 


1 2 3 

IZ 34 5) 6 TB 9 Od 2 34 3-6 7 BOO T 2 3 A567 89 OF 12 
4+--------------- D E a E E 4+--------------- + 
| Checksum | Version | Type 
4+--------------- 4+--------------- +--------------- 4--------------- + 
|Length |Local Port | 
4+--------------- phis +--------------- +--------------- + 
|Foreign Port | Longword Alignment Padding | 
4+--------------- E a +--------------- + 
|Buffer Number | 
+--------------- +--------------- +--------------- E T + 
|High Consecutive Seq Num Rcvd |Packet Number 

t--------------- p maa ternan aa 4+--------------- + 
|Data Area Checksum Value |Reserved (MBZ) |L] 
4--------------- +--------------- 4+--------------- A + 


Buffer Number The first buffer number starts at 0 

Hi Con Seq Num The acknowledgment for CONTROL messages 
Packet Number The first packet number starts at 0 
Data Checksum Checksum for data area only 

Reserved L: the last buffer bit: 0=false, 1l=true 


The NULL-ACK message type is sent as a response to a CONTROL_OK 
message that modifies the current packet size, burstsize, or 
burstrate. In acknowledging the CONTROL_OK message, the sender is 
confirming the change request to the new packet size, burstsize, or 
burstrate. If no modifications are requested, a NULL-ACK message is 
unnecessary. See Table 8, "NULL-ACK Message Type," for further 
details. 


Table 8: NULL-ACK Message Type 


1 2 3 

L 2s Bi. 6 EB OOO Te De BBE S67 8. QUO: dy DP" 3) AB 67 Bs 39.0? 2 
+--------------- +--------------- +--------------- +--------------- + 
| Checksum | Version | Type 
+--------------- +--------------- +--------------- +--------------- + 
| Length |Local Port | 
+--------------- +--------------- +--------------- +--------------- + 
|Foreign Port | Longword Alignment Padding | 
+--------------- +--------------- +--------------- +--------------- + 
|High Consecutive Seq Num Rcvd |New Burstsize 
+--------------- +--------------- +--------------- +--------------- + 
|New Burstrate |*New DATA Packet size 
+--------------- +--------------- +--------------- +--------------- + 
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The CONTROL messages have three subtypes: GO, OK, and RESEND as shown 
in Tables 9-12. The CONTROL message common header may be followed by 
any number of longword aligned subtype messages. 


Table 9: CONTROL Message Common Header 


1 2 3 

dl 23 AB Or 7 829 Oo A? 3) A 607 8 OO D238 An Ss 67) 8 OB OF 1. 2 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
| Checksum | Version | Type 

4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
| Length |Local Port | 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
|Foreign Port | Longword Alignment Padding | 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 


Table 10: CONTROL_GO Message Subtype 


1 2 3 
12. Bie OER: BY 90 de 2B 4s 06, PB Oo TL 28 3A O28 BY OO. 2 
tee Sse Ss sess sHSS pronte E EE EE pri + 
| Subtype |Padding | Sequence Number 
terie eenei AA tett e nE Faten + 
|Buffer Number | 
toss aaa staan Satan E + 


Table 11: CONTROL_OK Message Subtype 


1 2 3 

L 23 A BG 890; de 23 4 e TBO: 0A 23 As SG 7B OOF L 2 
Peas Sl Sa SSS toa ssa toa 55555 to SSS SSSSSsSSas5 + 
| Subtype |Padding |Sequence Number 
toa sss Sea Seen See + 
|Buffer Number | 
phn ian carn ma Steen Statitudes pa T + 
|New Offered Burstsize |New Offered Burstrate 
A aeSssscas pasearen PoSSesHSHSssees a a + 
|Current Control Timer Value |*New DATA Packet size | 
toss 55555 tonsa toss asa toss asa + 
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Table 12: CONTROL_RESEND Message Subtype 


iL 2 3 

IZ 3A 6 TB OQ. 2b 343 6 7 8 9: Oe L 2 3 AU OF 89 OF 1? 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
| Subtype |Padding |Sequence Number 

4--------------- 4+--------------- 4+--------------- 4+--------------- + 
|Buffer Number | 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
|Number of Missing Packets | Longword Alignment Padding | 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
|Packet Number (2 bytes) CERE 

+--------------- 4+--------------- 4+--------------- 4+--------------- + 
|i; eos | Longword Alignment Padding | 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 


2.2 ETFTP COMMAND SET 


Being built from TFTP source code, ETFTP shares a significant portion 
of TFTP’s design. Like TFTP, ETFTP does NOT support user password 
validation. The program does not support changing directories (i.e. 
cd), neither can it list directories, (i.e. ls). All filenames must 
be given in full paths, as relative paths are not supported. The 
internal finite state machine was modified to support NETBLT message 
types. 


The NETBLT protocol is implemented as closely as possible to what is 
described in RFC 998, with a few exceptions. The client string field 
in the OPEN message type is used to carry the filename of the file to 
be transferred. Netascii or binary transfers are both supported. If 
enabled, new packet sizes, burstsizes, and burstrates are re- 
negotiated downwards when half or more of the blocks in a buffer 
require retransmission. If 99% of the packets in a buffer is 
successfully transferred without any retransmissions, packet size is 
re-negotiated upwards. 


The interactive commands supported by the client process are similar 
to TFTP. Here is the ETFTP command set. Optional parameters are in 
square brackets. Presets are in parentheses. 


fe help, displays command list 
ascii mode ascii, appends CR-LF per line 
autoadapt toggles backoff function (on) 


baudrate baud baud rate (16000 bits/sec) 

binary mode binary, image transfer 

blocksize bytes packet size in bytes (512 bytes/block) 
bufferblock blks buffer size in blocks (128 blocks/buff) 
burstsize packets burst size in packets (8 blocks/burst) 
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connect host [p] establish connection with host at port p 
exit ends program 

get rfile lfile copy remote file to local file 

help same as ? 

mode choice set transfer mode (binary) 

multibuff num number of buffers (2 buffers) 

put lfile rfile copy local file to remote file 

quit same as exit 

radiodelay sec transmission delay in seconds (2 sec) 
status display network parameters 

trace toggles debug display (off). 


2.3 DATA TRANSFER AND FLOW CONTROL 


This is the scenario between client and server transfers: 

Client sends OPEN for connection, blocksize, buffersize, burstsize, 
burstrate, transfer mode, and get or put. See M bit of reserved 
field. 

Server sends a RESPONSE with the agreed parameters. 


Receiver sends a CONTROL_GO request sending of first buffer. 


Sender starts transfer by reading the file into multiple memory 


buffers. See Figure 1, "File Segmentation,". Each buffer is divided 
according to the number of bytes/block. Each block becomes a DATA 
packet, which is concatenated according to the blocks/burst. Bursts 


are transmitted according to the burstrate. Last data block is 
flagged as LDATA type. 


+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 
| | | 0 | [ee a a Ue eae ee 
| +---+ +---+ +---+ +---+ +---+ +---+ +---+ 
+-] | --> +---+ +---+ +---+ +---+ +---+ 
M a ET E (OR ln Po E S S 
+---+ +---+ +---+ +---+ +---+ +---+ +---+ 


File Multi Buffers Blocks per Burst 

Figure 1. File Segmentation 

Receiver acknowledges buffer as CONTROL_OK or CONTROL_RESEND. 

If blocks are missing, a CONTROL_RESEND packet is transmitted. If 
half or more of the blocks in a buffer are missing, an adaptive 


algorithm is used for the next buffer transfer. If no blocks are 
missing, a CONTROL_OK packet is transmitted. 
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Sender re-transmits blocks until receipt of a CONTROL_OK. If the 
adaptive algorithm is set, then new parameters are offered, in the 
CONTROL_OK message. The priority of the adaptive algorithm is: 


- Reduce packetsize by half (MIN = 16 bytes/packet) 
zs Reduce burstsize by one (MIN = 1 packet/burst) 
= Reduce burstrate to actual tighttimer rate 


If new parameters are valid, the sender transmits a NULL-ACK packet, 
to confirm the changes. 


Receiver sends a CONTROL_GO to request sending next buffer. 


At end of transfer, sender sends a QUIT to close the connection. 


Receiver acknowledges the close request with a DONE packet. 


2.4 TUNABLE PARAMETERS 
These parameters directly affect the throughput rate of ETFTP. 


Packetsize The packetsize is the number of 8 bit bytes per 


packet. This number refers to the user data bytes in a block, (frame), 


exclusive of any network overhead. The packet size has a valid range 


from 16 to 1,448 bytes. The Maximum Transfer Unit (MTU) implemented in 


most commercial network devices is 1,500 bytes. The de-facto industry 
standard is 576 byte packets. 


Bufferblock The bufferblock is the number of blocks per buffer. 
Each implementation may have restrictions on available memory, so the 
buffersize is calculated by multiplying the packetsize times the 
bufferblocks. 


Baudrate The baudrate is the bits per second transfer rate of 
the slowest link (i.e., the radios). The baudrate sets the speed of 
the sending process. The sending process cannot detect the actual 
speed of the network, so the user must set the correct baudrate. 


Burstsize The burstsize in packets per burst sets how many 
packets are concatenated and burst for transmission efficiency. The 


burstsize times the packetsize must not exceed the available memory of 


any intervening network devices. On the Ethernet portion of the 
network, all the packets are sent almost instantaneously. It is 
necessary to wait for the network to drain down its memory buffers, 
before the next burst is sent. The sending process needs to regulate 
the rate used to place packets into the network. 
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Radiodelay The radiodelay is the time in seconds per burst it 
takes to synchronize with the radio controllers. Any additional 
hardware delays should be set here. It is the aggregate delay of the 
link layer, such as transmitter key-up, FEC, crypto synchronization, 
and propagation delays. 


These parameters above are used to calculate a burstrate, which is the 
length of time it takes to transmit one burst. The ov is the overhead 

of 72 bytes per packet of network encapsulation. A byte is defined as 

8 bits. The burstrate value is: 


burstrate = (packetsizetov) *burstsize*8/baudrate 


In a effort to calculate the round trip time, when data is flowing in 
one direction for most of the transfer, the OPEN and RESPONSE message 
types are timed, and the tactical radio delays are estimated. Using 
only one packet in each direction to estimate the rate of the link is 
statistically inaccurate. It was decided that the radio delay should 
be a constant provided by the user interface. However, a default 
value of 2 seconds is used. The granularity of this value is in 
seconds because of two reasons. The first reason is that the UNIX 
supports a sleep function in seconds only. The second reason is that 
in certain applications, such as deep space probes, a 16-bit integer 
maximum of 32,767 seconds would suffice. 


2.5 DELAYS AND TIMERS 


From these parameters, several timers are derived. The control timer 
is responsible for measuring the per buffer rate of transfer. The 
SENDER copy is nicknamed the loosetimer. 


loosetimer = (burstrate+radiodelay) *bufferblock/burstsize 


The RECEIVER copy of the timer is nicknamed the tighttimer, which 
measures the elapsed time between CONTROL_GO and CONTROL_OK packets. 
The tighttimer is returned to the SENDER to allow the protocol to 
adjust for the speed of the network. 


The retransmit timer is responsible for measuring the network receive 
data function. It is used to set an alarm signal (SIGALRM) to 
interrupt the network read. The retransmit timer (wait) is initially 
set to be the greater of twice the round trip or 4 times the 
radiodelay, plus a constant 5 seconds. 
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wait = MAX ( 2*roundtriptime, 4*radiodelay ) + 5 seconds 
and 
alarm timeout = wait. 


Each time the same read times out, a five second backoff is added to 
the next wait. The backoff is necessary because the initial user 
supplied radiodelay, or the initial measured round trip time may be 
incorrect. 


The retransmit timer is set differently for the RECEIVER during a 
buffer transfer. Before the arrival of the first DATA packet, the 
original alarm time out is used. Once the DATA packets start 
arriving, and for the duration of each buffer transfer, the RECEIVER 
alarm time out is reset to the expected arrival time of the last DATA 
packet (blockstogo) plus the delay (wait). As each DATA packet is 
received, the alarm is decremented by one packet interval. This same 
algorithm is used for receiving missing packets, during a RESEND. 


alarmtimeout = blockstogo*burstrate/burstsize + wait 


The death timer is responsible for measuring the idle time of a 
connection. In the ETFTP program, the death timer is set to be equal 
to the accumulated time of ten re-transmissions plus their associated 
backoffs. As such, the death timer value in the OPEN and RESPONSE 
message types is un-necessary. In the ETFTP program, this field could 
be used to transfer the radio delay value instead of creating the two 
new fields. 


The keepalive timer is responsible for resetting the death timer. 
This timer will trigger the sending of a KEEPALIVE packet to prevent 
the remote host from closing a connection due to the expiration of 
its death timer. Due to the nature of the ETFTP server process, a 
keepalive timer was not necessary, although it is implemented. 


2.6 TEST RESULTS 


The NETBLT protocol has been tested on other high speed networks 
before, see RFC 1030 [6]. These test results in Tables 13 and 14, 
"ETFTP Performance," were gathered from files transferred across the 
network and LST-5C TACSAT radios. The radios were connected together 
via a coaxial cable to provide a "clean" link. A clean link is 
defined to a BER of 10e-5. The throughput rates are defined to be the 
file size divided by the elapsed time resulting in bits per second 
(bps). The elapsed time is measured from the time of the "get" or 
"put" command to the completion of the transfer. This is an all 
inclusive time measurement based on user perspective. It includes the 
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connection time, transfer time, error recovery time, and disconnect 
time. The user concept of elapsed time is the length of time it takes 
to copy a file from disk to disk. These results show only the average 
performances, including the occasional packet re-transmissions. The 
network configuration was set as: 


ETFTP Parameters: 


Filesize 
Radiodelay 
Buffersize 
Packetsize 
Burstsize 


101,306 bytes 
2 seconds 
16, 384-131,072 bytes 
512-2048 bytes 

8-16 packets/burst 


Gracilis PackeTen Parameters: 


0 TX Delay 400 milliseconds 

1 P Persist 255 [range 1-255] 

2 Slot Time 30 milliseconds 

3 TX Tail 300 milliseconds 
4 Rev Buffers 8 2048 bytes/buffer 

5 Idle Code Flag 

Radio Parameters: 

Baudrate 16,000 bps 
Encryption on 


Table 13: ET 


+ a Sg Pa sha eh 9B a eg tp Se 
|buffersize 
| (bytes) 

+ fe a Sea eet a ee a 
| 16,384 
+ SSS SSeS 
| 32,768 
+ Ste et ee ae ae 
| 65,536 
+ eek at lg a pe esl ge 
| 131,072 
+ saN Fea hats a ae ae te 


FTP Performance at 8 Packets/Burst in Bits/Second 


S arainn e E E t----------- S n EEE + 
|packetsize |packetsize |packetsize |packetsize | 
|2,048 bytes|1,448 bytes|1,024 bytes|512 bytes | 
A E EN t----------- Toenni t----------- + 
| 1,153" | 6,952 | 6,648 | 5,248 | 
t----------- t----------- t----------- S S + 
| 7,652 | 7,438 | T152) 4,926 | 
S e S t----------- t----------- t----------- + 
| 8,072 | 8,752 | 8,416 | 5,368 | 
AEE ESSE PARES ATREA +----------- +----------- + 
| 8,828 | 9,112 | 7,888 | 57128 | 
t----------- t----------- A nE RES D EE + 
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Table 14: ETFTP Performance at 16 Packets/Burst in Bits/Second 


+----------- toss SSSes FHSsSeessSe5 D ata O + 
|buffersize |packetsize |packetsize |packetsize |packetsize | 
| (bytes) [2,048 bytes|1,448 bytes|1,024 bytes|512 bytes | 
+----------- +----------- +----------- +----------- +----------- + 
| 16,384 | 5,544 | 5,045 | 4,801 | 4,570 | 
+----------- +----------- +----------- +----------- +----------- + 
| 32,768 | 8,861 | 8,230 | 8,016 | 7,645 | 
| oer io ot fae eS tS E E a Ste sa FHS SSe a SeaHas + 
| 65,536 | 9,672 | 9,424 | 9,376 | 8,920 | 
n A E SEA Forener paretari pateta + 
| 131,072 | 10,432 | 10,168 | 9,578 | 9,124 | 
pannan A a T A T A E A Trenat + 


2.7 PERFORMANCE CONSIDERATIONS 


These tests were performed across a tactical radio link with a 
maximum data rate of 16000 bps. In testing ETFTP, it was found that 
the delay associated with the half duplex channel turnaround time was 
the biggest factor in throughput performance. Therefore, every 
attempt was made to minimize the number of times the channel needed 
to be turned around. Obviously, the easiest thing to do is to use as 
big a buffer as necessary to read in a file, as acknowledgments 
occurred only at the buffer boundaries. This is not always feasible, 
as available storage on disk could easily exceed available memory. 
However, the current ETFTP buffersize is set at a maximum of 524,288 
bytes. 


The larger packetsizes also improved performance. The limit on 
packetsize is based on the 1500 byte MTU of network store and forward 
devices. In a high BER environment, a large packetsize could be 
detrimental to success. By reducing the packetsize, even though it 
negatively impacts performance, reliability is sustained. When used 
in conjunction with FEC, both performance and reliability can be 
maintained at an acceptable level. 


The burstsize translates into how long the radio transmitters are 
keyed to transmit. In ETFTP, the ideal situation is to have the first 
packet of a burst arrive in the radio transmit buffer, as the last 
packet of the previous burst is just finished being sent. In this 
way, the radio transmitter would never be dropped for the duration of 
one buffer. In a multi-user radio network, a full buffer transmission 
would be inconsiderate, as the transmit cycle could last for several 
minutes, instead of seconds. In measuring voice communications, 
typical transmit durations are on the order of five to twenty 
seconds. This means that the buffersize and burstsize could be 
adjusted to have similar transmission durations. 
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4. SECURITY CONSIDERATIONS 


The ETFTP program is a security loophole in any UNIX environment. 
There is no user/password validation. All the problems associated to 
TFTP are repeated in ETFTP. The server program must be owned by root 
and setuid to root in order to work. As an experimental prototype 
program, the security issue was overlooked. Since this protocol has 
proven too be a viable solution in tactical radio networks, the 
security issues will have to be addressed, and corrected. 
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6. GLOSSARY 


ATD Advanced Technology Demonstration 

AX.25 Amateur Radio X.25 Protocol 

BER Bit Error Rate 

EPLRS Enhanced Position Location Reporting Systems 
ETE TP Enhanced Trivial File Transfer Protocol 

FEC Forward Error Correction 

FTP File Transfer Protocol 

HF High Frequency 

LCU Lightweight Computer Unit 

ms milliseconds 

MTU Maximum Transfer Unit 

NETBLT NETwork Block Transfer protocol 

NITES National Imagery Transmission Format Standard 
PC Personal Computer 

RNC Radio Network Controller 

SAS Survivable Adaptive Systems 

SATCOM SATellite COMmunications 

SCO Santa Cruz Operations 

SINCGARS SINgle Channel Ground and Airborne Radio Systems 
SLIP Serial Line Internet Protocol 

TACO2 Tactical Communications Protocol 2 

TCP Transmission Control Protocol 

TETP Trivial File Transfer Protocol 

UDP User Datagram Protocol 

UHF Ultra High Frequency 


* Modification from NETBLT RFC 998. 
* The new packet size is a modification to the NETBLT RFC 998. 
* The new packet size is a modification to the NETBLT RFC 998. 
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